自動化測試、自動化測試，一樣的話不知道聽多少遍了，大家都知道要做自動化測試，但是真正能做到的有幾個？首先，『趕進度都沒時間了，沒時間寫測試』是我聽過最多的原因。我沒有辦法解決你沒時間寫測試的問題，因為，這代表你的工作環境不把測試當成你的工作，而且，加班寫測試也不就失去了本意。除非你把這件事當成興趣，或是學習技術，以side project的方式來在閒暇時間做，那還勉強OK。

在敏捷開發的洪流中，比較麻煩的是一種『我覺得我已經很敏捷了』的人。他不願意改變，他覺得這樣已經『夠敏捷』了。這種人，你很難動搖他的心智，因為他認為，『這麼敏捷了，還要改善什麼？』-- Well, 你發現這句話的矛盾了吧！

敏捷開發的重要精神就是持續改善，有敏捷精神的人，會在任何時刻有不需改善的想法嗎？

自動化測試也是一樣，如果你認為『這麼自動化了，還要改善什麼？』那你就是犯了跟上面抗拒敏捷的人一樣的錯了。我舉個例子吧：

我的產品中，有一個『客戶單筆消費明細』功能，我寫完了，也寫了測試。這個測試很簡單，我們有一個RD共同開發的環境，於是我在該類別中埋下一個main，我每次想驗證此類別有沒有被改壞，就去執行那個main，他會去讀取一批我事先在該環境準備好的資料，並且秀在螢幕上。

『只要這個測試用的main正常跑完，我只要一眼就能看出這個報表功能壞了沒，因為這個結果是固定的。』

這樣做算是自動測試嗎？嗯...well,...這要看你有沒有付我顧問費來回答你這個問題...

哈！開玩笑的啦，當然不算啊！
這樣充其量只能算是『跑個結果出來，並檢查一下對不對』
這種事連QA都懶得手動做了，你都動手寫程式了，怎麼才寫成這樣？
（請原諒我說話就是這麼直）

如果你所謂的『自動測試』長得像上述故事這樣，我們來看看你至少有哪些可以更好的做法

不要跟別人共用資料庫

資料自己準備是好事，但是一旦用了共用資料庫，難保你的測試資料不會被別人不小心竄改。最好的做法，是有一個自己的空白資料庫，管你要架在自己電腦還是偷偷在公司伺服器裝一個。反正裡面只能有你的資料，而這個資料庫最好是隨時保持全空狀態（只有Schema），在每個測試案例要開始前，才去創一些這個案例專用的資料，並且在測試完後刪除，留下乾淨的資料庫給別的測試案例用。

關於這點，也許你有存疑，但因篇幅有限，歡迎參考拙作『談測試的資料』，裡面有比較詳細的論述、原因、與建議做法。

不要另寫main來測試你的功能（就算寫了也不要跟別人講）

現在已經是2017年了，不管你是前端還是後端，甚至是網頁，都有不只一種的自動化測試框架，即便是worst case，都可以按一個鍵，就跑完此專案內所有測試。因此，像『寫一個只有自己知道在哪裡的main來慢慢測』這種大學時代的做法，我們就盡量不要用了。（就算用了也不要跟別人講）

我絕對不是說舊方法不好
我絕對不是說舊方法不好
我絕對不是說舊方法不好

舊方法很好。因為，舊方法會存在，肯定是因為在那個年代，他是最適合的做法，我們必須給予肯定。但是同樣的精神留著，可以拿來套用在比較方便又全面的技術上，何樂而不為呢？

請記住，測試，尤其是功能性測試，是跑再多次也不會嫌煩的。如果不能至少做到一鍵執行所有測試案例，在21世紀的今天，就不太被認為是『自動化』的測試方式。

能夠用肉眼比對的『值』，就一定可以叫程式幫忙比對

沒有什麼是不能比較的。如果你的物件欄位有10個，那就叫程式幫你比對這10個欄位。如果你預期某行Log會出現10次，那就叫程式去屬看看是否真的印了10次。如果你預期這樣跑完資料庫會新增20筆資料，每筆資料5個欄位，那你就叫程式去整張table取出來，先數數看是不是真的有20筆，再一筆一筆對看這5個欄位是不是預期的值。

當然，除了一些圖案顯示性的功能比較難用程式比對以外，舉凡是資料正確性、特定method被呼叫次數、連線建立數等，只要是你用眼睛看得出pass或fail的值，都可以讓程式用同樣標準去檢視。你說你肉眼看一下很快，問題，你有比電腦替你看還要快嗎？一次努力，永久受惠，多划算啊？

可以想到時手動驅動一下，但是至少你要每天『自動』驅動一次全部測試案例

半自動測試另一個有可能引發問題的地方，就是你必須時不時地想到，然後去跑一下。問題就在，你跑了30次都pass，然後隔了一周才想到，再去跑第31次，問題就往往出在這一周的空檔。

理想狀態下，我們會希望每次commit，或至少每次push，就能自動觸發此專案中的所有已存在test case。如果這件事很難，那麼你至少要排程，讓他每天自動地跑一次。既然是排程，時間就可以訂在大家都下班後的深夜了。而排程的好處很明顯：『你會忘，但電腦不會。』

至少，你每天一進公司打開email，就知道昨天我們團隊做的所有更動，把哪些其他功能搞壞了。記得我們前文說的嗎？痛苦的是要讓他提早發生。debug夠痛苦了吧？那就讓bug一旦被製造出來，就馬上被抓到吧！

隨時思考有沒有更『懶』的空間

以上只是一些基本步驟，還有更多更深的理論在背後，但是身為工程師，如果我們沒有要追求極致完美，至少我們要做到有信心。譬如：

我的主線上的程式，老闆隨時有需要，我都有信心他可以馬上讓測試人員檢測，測完馬上上線。

你如果初期能做到這種程度，其實也就夠了。

接下來就是在開發過程中，持續補強，持續讓流程更自動化 (aka更懶)，並持續改善你的工作流程，當然也包含你的『自動化腳本』本身。請記住：

在敏捷的世界裡，唯一不變的事情，就是『改變』這件事本身。